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(54) File system interface to a database 

(57) Infonnation in a database Is accessed with a 
computer system by transforming a file system request 
from an application into a database query and retrieving 



information corresponding to the database query from 
the database. The retrieved information is made avail- 
able to the application as a file system object, for exam- 
ple, as a directory, a file, a link or a collection thereof. 
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cription 



This invention relates to accessing information in a 

.joined") to each othenn v'^ualy a Y ^ ^^^^^.^^^ 
base developer .^'^'^jS^ 
database can be '"^^'^ / .^^f ^database engine 
relationships between the »^^'l'!^ ';^^tional database 
may perform complex searches "^^ .^^'^^^^^ 
c,u,L'^ and easily bv usingany^^^^^^^^^ 
ryprotocolssuchasthemjhodexpre J^^^^ 
tared Query language (SQL) o by ot 
The relationships '^^^^^^"'.roS referenced to corre- 
a search to be Ir tXsS^^^^ As 

sponding information ^'^f ^^^^It ^^a, database 100 
shown in Fig. 1, for pined by a log- 

includes a customer ^al^le 02 wn^ 's ) ^^^^ 
icallinklOStoanordertableWwhi^^^^^^^ ^ 

by a logical link 105 to ""^^ or all order 

may query the database 0^^^^^^^^ 
numbers higherthan athresholdvju 2 ^ 

dertable104lsio,nedwm.^t^2-^^^^^ 
the inventory table 1 06, the iisx o. ^ ^^ong 

that correspond to .qodB) is a collection 

An object-onenteddatab^e (^u J ^^^^ 

of "Objects- - - 
and rules for ^^^^^"^^^TT.S^onW character-type 
lational database which can store only 
data, an OODB can store da a °' -^^^^^"^^^^ 3 ores 
3D graphic ^'^'at^archyd daises wfth as- 

ns constituent °^>-j ;3^SJDB7°"'-ins much of the 
sociated rules so that °OU ts database 
logic it needs to do useful work^ A r^i ^^^^^^ 
incontrast contains only d^aandr^^^^^^^^^^^ 
application softNwareto perform usetui 



,,,, ..„o.d».-.m^^^^^ 
large obiaol (BLOB) an u ^^^j „t,mn a 

™rB::T'S"rra..,^a^^^^^ 

Womb* Unl.et5al saivot (IDS®) » a" '^i' 



BUS) tW Wen»«y " ™™ „ .„aive- dala 

!;r-;^tr™ir«oBo.Ms,„...as 

function. For example, a f '^^y^^/,,^^^ ^ database 
,0 thatratriavesalistoicus^^^^^^ ^..^ 
which stores 

d«erantapplicat.nprojam^^^^^ 
database queries and which ano 

tomtulate a database ^^^-y^^^^, Jf^'J^state custom- 
,5 setofcriteria(a.g.,thenameso^^^^^^^^^ 

erswithoverdueac.ount VT^^^^^^ que^ to the data- 
gram presents the users o-vo ^ information 

base engine which f '^^f^^J^J^^^^ograms are re- 
irom the database. S"chJP^°^^'°^ have 
,0 lerred to as '^^^"^^^'.rT^^MalB databases, 
the ability to interact with ^fj^^^^,^^^,^ are "data- 
Most application P'^l^^^ cannTsccess infor- 
base-unaware- meanH^g that^^^^^^^ 
rnation stored «.adambase^R^^ ^^^^ 

,5 applicattons rej on ^^^J^J^' sun Microsystems. 
File system (NFS) developed V ^^.^^ 
inc.. for storing and g^^res each sepa- 

rate document n a ^eP^^^ ^ ^^^n^pie , a file sys- . 
,0 user of the application. In '^'S-^' ^ ^ 202 which 
tern 200 has two disk dr^es '^ou^^^^^^^ capped 
■.smappedtothelabaa^and^ 
to the label b:. Each of the a^ano 

^,-r2; and so on with virt^al^ a^^^^^^^^^^ ^^^^^ 
nesting being possible. 13^^,3 v/ithin the 

01 the various directory or ^^b^rectory^ _ 
file system. The labels a. . ^P esen^^ ^^^^^^^^ 
space- of the file system, ^^at is, a 
b'egin w.h or are ^f^^^^^^^^ 
space. AS shown in Fig. 2, ^^^^^ the file 

names of out-of-state =«e "n^d by the fileoa- 
« system's "amespa^s a a Joca.on ^^^^ ^^^^^ ^^^^ 
me path «:Wocs^«st out ^„ 
a file 211 named ^^^^-"f^ls on a disk drive 202 
stored in a ^'-^J^^ Th" document that lists 

mapped to the label a Anothe ^^^^^^ 



■-lurrniigiy 

^ In one aspect of the invention, intormation in ada- 
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.taBasB is accessed with acpmputer system by making 
one or more'ciat^basesiEibiaets (e.g., a table or a row) 
available as one or^&ipfdersystem objee^ts (e;g., direc- 
■tor-|es^Wgstoi1iriks)ito aTTaBpjiGationEfor axairipie, a da- 
The'database may be re- 
m(mm^eWe^^^r^obi9Cl<>ndfiXe6. If multiple 
nie system objects are made available, collectively they 
may represent a|Rie^arohicaJ^|^§^ys^ A file system 
request issued by the application that corresponds to 
the file system object is transformed into a database op- 
eration, for example, an SQL query, which is performed 
on the database with a database engine. 

Information associated with the database object 
which is retrieved as a result of the database operation 
may be formatted into one'^inli9rsygi|i^xSte^ 
and retumed to the application. The paificulair f oirnattTng 
of the retrieved information may be defined in an exten- 
sion module, which also nnay include infonnation that 
defines the specific manner in whichjthe file s)(Stem,re- 
quest should Be transformed intc^data&ase query. The 
database operations, including formatting of a database 
query, retrieving information arid formatting It into file 
system objects, are performed transparently to the ap- 
plication. 

Upon receiving the file system objects, the applica- 
tion mayidisptayilham on;a displaj^ of a computer, 
for example, as'graphicalJrepresqntations.pf.filB.systern 
objects The database object that is made available may 
be presented as multiple file system objects in*fbmnats 
understandable^byjdifferent apgjicatlons. Conversely, a 
singlSjiieisystBm may correspond to multiple da- 
tabase objects. 

In another aspect, a computer-based data reposi- 
tory management system includes a database of infor- 
mation, a file system-based application program for ma- 
nipulating data, and a file system interface to the data- 
base which provides the file system-based application, 
which otherwise. may be database-unaware, with ac- 
cess to infornnation in the database. The data repository 
management system may further include a database 
managernent system which manages information in the 
database either in addition to, or instead of, the file sys- 
tem-based application. 

The data repository management system may in- 
clude a module for differentiating. file system requests 
directed to the file system from file system requests di- 
rected to the file system interface. The file system inter- 
face may include one or more extension modules con- 
taining one or more file objects, each file object including 
information for converting database objects into file sys- 
tem objects. 

In another aspect, information in a database is ac- 
cessed with a computer system by encoding a file han- 
dle with information that specifies a database object In 
a database. In respbfiseito>a file, system request-issued 
by an applicatiorilithe'encoded file handle is transmitted 
and then decoded to identifyahe database object.esso- 
ciated with the file systemTrequest- The encoding may 



be based on the NFSprotocol. The encoded information 
may include" information that corresponds to the issued 
file system request and which identifies an extension 
module, a database table and row, metadata, a pointer 
s to a database object, or a combination thereof. 

Advantages of the file system interface described 
here may Include one or more of the following.-Applica- 
tiori&that rely on a file system as a data repository, or 
which are otherwise datatjase^unaware (i.e., unable to 
70 access data in a database), are" enabled to access in- 
formation in a database in a transparent manner. These 
database-unaware applications can share data seam- 
lessly both with database-aware applications and with 
other database-unaware applications. , Under IXFS. a 
IS daplpase rri^y^appear to an application as just another 
lo^} oKremote;;;fije . system tha^ is no .different in, form or 
chSracterfrorntRebtlierfile'system 
pli^tion.- No change to the application's program code, 
the database or the database engine is required. As a 
20 result, users of database-unaware applications are pro- 
vided with database functionality without having to in- 
vest the time and cost typically associated with data- 
base-aware tools. 

A system administrator may use the IXFS system 
ss to combine disparate data storage technologies (e.g.. 
fileTI based systems with database systems) in creating 
a unified data repository strategy that spans an enter- 
prise. The enterprise's investment in legacy data repos- 
itories is maintained because data present in the repos- 
30 itories nnay easily be transferred to a database as the 
enterprise moves to the relational or object-relational 
model of data storage. Moreover, the enterprise's in- 
vestment in database-unaware applications is en- 
hanced because IXFS enables them to be used to man- 
3S age data stored in a.database. 

The ability for a database-unaware application to 
access information in a database combines the simplic- 
ity of the file system paradigm with the sophistication 
and effectiveness of database manipulation techniques. 
40 This capability is particularly useful for Internet World 
Wide Web applications in which a user seeks to access 
a large store of data using, for example, the hypertext 
transfer protocol (HTTP)- contrast to a common gate- 
way interface (CGI) script, which spawns an external ap- 
45 plication to retrieve data from a database in response to 
a URL (Uniform Resource Locator) encoded request, 
the?JXFS.,systeflti^c$?nverts such a request into a form 
thatlriay'Be^ecuted fay a database -engine directly, 
quickly and tansipare ntly.l 
so The abilify to represent an arbitrary collection of ta- 
bles in a database as various file system objects pro- 
vides a software developer with a rich and flexible set 
of tools. The extensible nature of IXFS allows it to be 
tailored to virtually any type of application so that the 
ss database will appear as a collection of file system ob- 
jects that are consistent with the application's other file 
system objects. 

Other advantages and features will become appar- 
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ent from the lollowing description, including the draw- 
ings and claims. 



Fig 1 is a diagram of a relational c 
^;^tli^SS:;^VS=accessingdata 
*""pS'^rL^:;:nSS^slngdatainadata.ase 

r S and are example screen displays 
from an appVatlon accessing inlcrmatiun in a f.le sys- 

ng aSaTructure diagram tor a tile object 
Fig. 7 is a diagram of a kernel level file system ar- 

''%t" is a diagram o1 a network file system archi- 
^"%Tg. 9isadata diagram Of aNFSfileh^dle as used 
in the network file system architecture of F.g. 8. 



The use Of a database to store persistent data pro- 

ThiLmongotherreasonsis>^yapprox.^^^^^^^ 
o1 all persistent data is stored m f.le systems oy oa 
base-unaware applications. ^ ^bed 

The file system interface descnbed nere, °" 



?lation toSfess the,^^^^^ by per- 

5^SSSU-s|t^^r---°^*^°^^ 

t^at represent tH^f -^J^gJ^J.etween a data- 
lion as one-ormbreffle-system^&jeets^^ .ypsand 

Serfhe request has translated into a database quen. 

predefined crrteria into Hie ^systern o^ ^^^^^'^^^^^l 
which are presented to the application (step 410). Upon 
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space are handled by the file system while all requests 
for data in the file namespace assigned to the database 
are handled by IXFS. 

An example of how IXFS may be used to represent 
a-B^tabase,^s atftle. systernlto an application is provided 
wRh"reference to Figs. 5A-5C. Assume that a user of a 
window-based computer system uses aSl^systerti-nav- 
igatidnrtopl to examine th e information that is stored both 
in the file system represented by Fig. 2 and in the data- 
base represented by Fig. 1 . Assume further that the file 
system's namespace Is represented by the labels a: and 
b: and that IXFS.is-mapped todrK/e jif;.on the client ma- 
chine. As shown in Fig. 5A, the navigation tool window 
500 initially displays the file system's two drives, a: and 
fe, and the drive jr; corresponding to the database, in a 
collapsed state. At this point the user instructs the nav- 
igation tool to expand cljtivejib;, thereby malcing its hier- 
archy of directories and subdirectories vhsible to the us- 
er, and- opens subdirl which contains two files, 
doe206.txt and doc207.txt, as shown in Fig. 5B. The 
file Infonmation displayed in Fig. 5B is retrieved from the 
a. and b: drives using standard file system operations. 

Next, the user instructs the navigation tool to ex- 
pand drive x:, which is mapped to the database via 
IXFS, so that the contents of drive x: may be examined. ■ 
Because the corresponding file system request Issued 
by the navigation tool points to drive x. ~ the file name- 
space assigned to the database - IXFS handles the file 
system request by passing it to an extension module 
which formulates a database query to retrieve the re- 
quested infonmation from the database. After the infor- 
mation has been retrieved, it is formatted into file system 
objects with a method invoked by IXFS and returned to 
the navigation tool. The information retrieved from the 
database appears to the navigation tool, and to the user 
of the navigation tool, to be no different in characterfrom 
other file system objects that were retrieved with the file 
system. As shown in Fig. 5C, tables 102, 104 and 106 
in the database 100 of Fig. 1 are represented as three 
corresponding directories -customer, order and In- 
ventory. Similarly, three rows within the customer table 
102 — customer_name, customer_addr and 
customerjd — are represented as three corresponding 
subdirectories within the customer directory — name, 
address and id. Entries in the name subdirectory are 
represented as text files that are named for their respec- 
tive contents - Adams, Andrews, Brewster, etc. 

A user may open any of the text files in the x:\cus- 
tomerlname directory (for example, with a. standard text 
editor application) modify Its contents, and perform a 
standardiffne^avi^Ioperation. In response, IXFS han- 
dles the ffle save requeit because it is directed to the 
file namespace assigned to the database and formu- 
lates a corresponding database operation to modify the 
contents of the database as appropriate. 

IXF,S-,allows:airjfile. system operations to be per- 
formed;ori:tlie-.datat5ase. For example, a user could em- 
ploy appropriate features of the navigation tool to 



change the name of the xrlcustomer d irectory to some- 
thing else such as x:\cust Similarly, a user could create 
a new file system object such as a subdirectory or a new 
file underneath the xrlei/stomor directory. Moreover. 
5 access to specified portions of the database could be 
limited for certain users in the same mannerthatfile sys- 
tem objects in a file system nnay be limited (read only, 
hidden, etc.). 

jT- The specific types, formats and arrangement of file 

10 * system objects that IXFS will return in response to a file 
system request are defined in a corresponding exten- 
sion module ~ a software component of IXFS that may 
be tailored as desired to encapsulate an arbitrary col- 
lection of database objects (e.g., tables) and represent 

»5 them as a collection of file system objects. In one imple-^ 
mentation. IXFS jncludes^i. Basic E>rtenslori Module* 
(BEM) that provides a GOgrfgone^^ a file in a 

file system- into-a c6flli5tion of database objects. Ajgong 
other uses, the BEM allows users to quickly andtfa'ns- 

so parentlyTnovet'heir data from a file system intothelUS® 
daTabase management system and run database que- 
ries against it. 

The BEM emulates a file system by encapsulating 
a collection of database gables ;as specified by a Sott- 
as ware developer implementing the IXFS system, and 
presenting them to an application as file system objects: 
Each table specified by the BEM corresponds to a di- 
rectory and each row in the table corresponds to a file 
system object (e.g., subdirectory, file or link) present 

30 within the directory.* 

For each database table that it encapsulates, the 
BEM includes a corresponding^'file object" 600 having 
a data structure as shown in Fig. 6. Thejile.system. (jBr? 
ject 600 corresponds to, and provides an intuitive rep- 

35 resentation of, aairectoFy.^pebr aliiik.in.d file system. 
Each f|Le.pbject.'600 includes the file object's name 601 
(an identifier of a file system entity that is unique within 
"a given directory), type 602 (directory, file or link), own- 
ership 603 (an Identifier of the file object's owner), ac- 

40 cess rights 604-(access.Tiglifs;to the object for its owner, 
community and others), temjaoral characteristics 605 
(timestamj>,oyast operations), 
popularity 606 (number of links pointing to the abject) 
and size 607 (object's size in bytes). The file object 600 

4S also contains its corresponding data object 608 or a 
pointer to the data object^^ 

Portions of a database are mapped to a file system 
representation by selecting database tables and rows 
as desired, and by designating" the type of file -system 

so oBjectito which each selected table and row corre- 
sponds. For example, the database of Fig. 1 ' was 
mapped into the file system hierarchy shown in Fig. 5C 
by specifying that each of the customer, order and in- 
ventory tables occupy a separate file object In the BEM 

£5 of the type "directory. ° Within the file object for the cus- 
tomertable, each of the name, address and id rows have 
been designated as the type "directory, " thereby making 
them appear as subdirectories to the hierarchically dom- 
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sented as a single file system object e.g^, 
Exce, file "-^^"-^^o'^S^nrS S^d be 

who edited the Information in the Adamsxio , 
wSd observe that the djSaaS^^^f^^^^^^^ . 

information stored in a database to store new or m 
ena Je a single enterprise-wide data reposrtory to be 



maintained with various B^eref appli» both da- 
Sase-aware -ddatab se-— ^^^^^^^^^^ 

^^'CScFrsTie-maybaimplernentedbythreed^ 
. ^^—^^^^ 

ireSra^n-^rrr^p 

;r~sJbas3.p.a^^^^^^^ 
set of file system "^J'^'^vide a functionality 

database, ^-^^^'^^^.tyThe' Smmon file access 
20 analogous to that P"^^^° ;,p,3) defined by the 
Application Prog^mln^ert^^^^ ^^^^ 
ANSI C or POSIX standards^ use '^^^ to 

be used 'J^^^^/^S'^jects. The other two archl- 

" ;L^u esT ' rL^ato^^ eilsting applications to ac- 
Sdiabaseinfom.ationwnhouta^ 

systen, for P^°=^=/'"%J.,f4Sd to include an IXFS 
kernel module 701 when ^ ,^5,^ gyg^er^ 

35 tern being used (e.g. , UNIX, ^'^ received by the 

cation ^^''^'"S ^;^,7^^„^706 (an application residing 
by m. IXFS ksm. ,„ oa« ol 
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ing the specified filenapne to a list of names of file objects 
contained in each extension module. After determining 
which IXFS extension module includes a file object 
whose name matches the specj|ied filename, the IXFS 
daemon 708 transfe rs the (f^quest^ o that extension 
module 7 07. The extension ^gQOfjule |^slgtes the re- 
'questJnt p£a'database operation which J s performed on 
"th e database 7 09. Any information generated in re- 
sponse to thedatabase-,query operation is formatted by 
a method invoked by the IXFS extension module 707 
into file system objects according to the f ile object ttf pes 
defined in the extension module. The formatted file sys- 
tem objects are then presented to the requesting appli- 
cation.^ 

The network architecture, illustrated in Fig. B, inter- 
cepts file system requests at the network level and pass- 
es them on to the IXFS system for processing. In the 
network architecture, the OS kernel address space 
need not be modified. Rather, all file system commands 
generated by a local client 805 or a remote client 806 
are passed, via a loop NFS connection 810 or a network 
NFS connection 803, to a NFS front-end daemon (or 
sen/ice) 804, which resides outside of the OS kernel. 
The NFS front-end daemon 804 is implemented as a 
component of the IXFS daemon. 

Upon receiving a file system request, the NFS front- 
end daemon 804 passes it on to the IXFS daemon 806 
and subsequently to the appropriate IXFS extension 
module 807, which provide the same functionality as the 
IXFS daemon and IXFS extension modules in the kernel 
level architecture described above. 

The IXFS system can be adapted to provide.'an in- 
terface toanytype of databas e.^ incl uding relational, ob- 
lect-reiational and object-origrited databg g°n h"'^ tn i m- 
derst and any other type: of -tlatabase query , protocol in 
addition to SQ L. NFS was chosen as the network pro- 
tocol to be used in the IXFS implementation of Fig. 8 
because NFS is a widely used standard for sharing files 
across different platforms. However, any other network 
protocol that provides access to file systems over a net- 
work "for example, Microsoft's Common Internet File 
System (CIFS) - could be used in implementing the 
IXFS network architecture. 

The NFS protocol (version 2) allows clients and 
servers to exchange file information by using a "file han- 
dle" — a 32-byte value — to identify a desired file. When 
NFS is used as the network file system protocol in the 
network architecture, IXFS can make additional use of 
the NFS file handle to achieve greater speed and effi- 
ciency in performing file system requests on the data- 
base. To do so. IXFS encodes the NFS file handle with 
information that is specific to its operations as shown in 
Fig. 9. 

Bytes 1-8 of the file handle hold the IXFS "magic 
string" ~ an entity that allows IXFS to distinguish IXFS 
file handles (i.e., file system requests directed to the file 
namespace assigned to the database) from NFS file 
handles (i.e., file system requests directed to the file 



namespace assigned to the file system). The magic 
string is an eight byte string In which each byte is as- 
signed the value FF hexadecimal to identify a file handle 
as an IXFS file handle. Bytes 9 and 10 identify the par- 

s ticular IXFS extension module whose job it is to manage 
the file handle under consideration. Encoding an IXFS 
file handle in this manner obviates the need to maintain 
an empty ("shadow") directory tree in the file system, 
which othenwise would be needed to generate standard 

10 NFS file handles that correspond to information man- 
aged by the IXFS system. Similarly, this encoding 
scheme makes it unnecessary to maintain a distinct 
mapping entity (e.g., look-up table) between NFS file 
handles and IXFS file handles. 

IS The remaining bytes of the NFS file handle in Fig. 
9 include information that is specific to the extension 
module identified by the extension module identified by 
bytes 9 and 10 of the file handle. Bytes 11-14 and 15-1 8 
respectively identify the database table and row that cor- 

20 respond to the file handle. Bytes 19-22 identify the i- 
node (information node) table and row which corre- 
spond to metadata descriptive of file attributes, and a 
pointer to the data in the database, for the file handle 
under consideration. Bytes 19-32 presently are unused 

2S but they are available for use by any newly developed 
extension modules. As a result of the encoding repre- 
sented in Fig. 9, the efficiency with which elements may 
be located in the database is enhanced and the com- 
plexity of designing new IXFS extension modules is re- 

30 duced. 

The kemel level and network architectures provide 
different advantages relative to one another. The kernel 
level approach is the more efficient of the two in that it 
provides a shorter data path between the issuance of 

35 the file system request to the return of file system objects 
from IXFS. On the other hand, the network-based archi- 
tecture significantly minimizes the effort required to port 
the IXFS between different platforms because imple- 
menting the network architecture does not require a 

40 modification to the operating system kernel. In both cas- 
es, however, the IXFS system provides a database-un- 
aware application with transparent access to data in a 
database, while maintaining the inherent advantages of 
using a database for persistent data storage. 

45 The methods and mechanisms described here are 
not limited to any particular hardware or software con- 
figuration, but rather they may find applicability in any 
computing or processing environment in which data- 
base manipulation may be performed. The tecnniques 

so described here may be implemented in hardware or 
software, or a combination of the two. preferably, the 
technique are implemented in computer programs exe- 
cuting on programmable computers that each include a 
processor, a storage medium readable by the processor 

55 (including volatile and non-volatile memory and/or stor- 
age elements), and suitable input and output devices. 
Program code is applied to data entered using the input 
device to perform the functions described and to gener- 
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ateoutputintormation.Theout put information is applied 
sLdal purpose programmable computer for configur 

eratlons: 

^eoe^,o a file system request issued by the file sys- 
tem-based application; t„ „ database op- • 
convert the file system request into a database op 

information from the ^^ta^^- ^^^^^^^ 

file system objects accordingto predetermined cn 
p.2enUhe one or more file system Objects to the 
file system-base application. 

A still further aspect provides a computer program. 
.esldln^Snacomp^er readable mediumcom^^^^^^ 
struction for implementing any method or system as 

scribed herein. 



Claims 

1 A method, performed on a computer 
ceTsinglntom.ationinadatabase.themethodcom- 

prising steps of : 

retrieving information from the database; and 
?e" anting the retrieved infom^tion to an ap- 
plication as a file system object. 

2 A method as claimed in claim 1 wherein the step of 
retrieving comprises the steps of: 
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making a database object available to an appli- 
'iS^^^^SJ^SS-afilesystemre- 
l^^eroCoSng'^thoavailab.^^ 

S:S;"ing the file system request from the 
application into a database operation. 

3 The method of claim 2 further comprising perform- 
-n^the database operation on the database us.ng 
a database engines. 
A The method of either of claims 2 or 3, further com- 
pJising retrieving information from the database ,n 
response to the database operation. 

> ject. 

B The method of claim 5 in which the returning com- 
X" arranging the retrieved information m a for- 
mat defined in an extension module. 
' 7 The method of claim 6 further comprising displaying, 
me fo^atted infomiation on a screen of the com- 
puter system, 

- ■ ssssz- 

ter system. 

^hL p,o»mrton ot a 111= .y".-" 

prises a database unaware application. 

11 The method of any preceding claim in which the da- 
Ibase comprises a relational database; or 
^ in which the database comprises an object-re- 

lational database; or 

in which the database comprises an object-ori- 
anted database. 

request into a database query. 
13 Themethodofclaim12inwhichthedatabasequery 
comprises an SQL-compliant query. 
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1 4. The method o1 either of claims 1 2 or 1 3 In which the 
transforming comprises converting the file system 
request into a database query based on information 
contained within an extension module. 

15. The method of any preceding claim further compris- 
ing determining whether the received file system re- 
quest corresponds to information managed by a file 
system; and, preferably, further comprising convey- 
ing the file system request to the file system if the 
file system request is determined to correspond to 
Information managed by the file system. 

16. The method of claim 15 in which the determining 
comprises identifying a namespace to vyhich the file, 
system request is directed. 

17. The method of either of claim 1 5 or 1 6 in which the 
determining is perfonmed by a method executing in 
a kernel address space of an operating system as- 
sociated with the computer system; or 

in which the determining is performed by a 
method executing externally to an operating 
system associated with the computer system. 

18. The method of any preceding claim in which making 
the database object available as a file system object 
is performed transparently to the application. 

19. The method of any preceding claim in which the da- 
tabase object comprises a table. 

20. The method of any preceding claim in which the file 
system object comprises a directory, a file or a link. 

21 . The method of any preceding claim in which making 
the database object available as a file object com- 
prises presenting the database object as a plurality 
of file system objects in formats which are under- 
standable by different applications. 

22. The method of any preceding claim further compris- 
ing identifying the information to be retrieved from 
the database by specifying a database object from 
among database objects in the database. 

23. The method of claim 22 in which the identifying 
comprises recording in an extension module infor- 
mation descriptive of a predetermined set of data- 
base objects. 

24. The method of claim 23 in which the receiving com- 
prises selectively extracting information from the 
database based on infomnation contained in the ex- 
tension module. 

25. The method of claim 24 in which the presenting 



comprises formatting the selectively extracted Infor- 
mation into file system objects based on information 
contained in the extension module. 

5 26. The method of an preceding claim in which a col- 
lection of file system objects represents a hierarchi- 
cal file system having directories, files, links or a 
combination thereof. 

10 27. The method of any preceding claim further compris- 
ing providing a file system interface to the database 
which provides the application, preferably a file sys- 
tem based application, with access to information 
in the'database. 

75 ' ■ 

• 28. The method of claim 27 further comprising provid- 
ing a module for differentiating file system requests 
directed to the file system from file system requests 
directed to the file system interface. 

20 

29. The method of either of claims 27 or 28 in which the 
file system interface further comprises an extension 
module that includes a file object. 

2s 30. The method as claimed in any of claims 27 to 29 in 
which the file object comprises information for con- 
verting database objects into file system objects. 

31. The method of any of claims 27 to 30 in which the 
30 file system Interface comprises a plurality of exten- 
sion modules each of which includes information for 
converting a different set of database objects into 
file system objects. 

35 32. The method of any of claims 27 to 31 in which the 
file system interface comprises a plurality of exten- 
sion modules each of which includes information for 
converting a single database object into multiple file 
system objects. 

40 

33. A computer based method of accessing Information 
in a dat^ase, the method comprising: 

encoding a file handle with Information that 
4S specifies a database object In a database; 

transmitting the encoded file handle In re- 
sponse to a file system request issued by an 
application; and 

so 

decoding the received file handle to identify the 
database object associated with the file system 
request. 

ss 34. The method of claim 33 in which the encoding is 
based on the NFS protocol; or 

in which the encoding comprises including in- 
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formation in the file handle that identifies an ex- 
tension module that corresponds to the issued 

file system request; or 

in which the encoding comprises including in- s 
formation in the file handle that identifies as a 
database table and row that corresponds to the 
issued file system request; or 

in which the encoding comprises including in- 'O 
fomiation in the file handle that identifies meta- 
data that corresponds to the issued file system 

request; or 

in which the encoding comprises including in- U 
formation in the file handle that points to the da- 
tabase object that corresponds to the issued 
file system request. 

35. A system for accessing information in a database. 2 
the system comprising 

means for implementing a method as claimed 
in any preceding claim. ^ 

36. A system for accessing intormation in a database, 
the system comprising: 

means for making a database object available 
to an application as a file system object; 

means for receiving from the application a file 
system request corresponding to the available 
file system object; and 

means for transforming the file system request 
from the application into a database operation. 



so 
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